Dynomotion

Group: DynoMotion Message: 11399 From: Hardy Family Date: 4/15/2015
Subject: Setting tool length offsets
Every tool change on our machine has a final step where it touches off the tool on a fixed height tool setter.  What I am trying to do is write the tool length back to KMotion-CNC, but I am getting some unexpected behavior: "old" tool heights are getting rolled out of the table.  For example, if I change from tool 1 to tool 3, then I can see the tool 3 entry being written (using the "edit" button on the tool panel) but tool 1's measurement disappears.  Not only that, the entry for tool ID 3 gets written to seemingly random entries in the tool table, sometimes leaving duplicate entries.

I'm probably just doing something wrong.  Here is how I have it coded so far:

At the end of running the kflop C program for M6, the program obtains the Z position where the touch-off occurs.  The code then runs the following routine to update the tool table:

// Main routine to update tool length offset to the CNC program.  Since we touch off
// tools to a fixed THS, we get a relative tool height by reading Z at the touch-off point.
// We set the current TLO from Z plus an arbitrary offset to make the TLO roughly correspond
// to the actual length projecting from the spindle nose, and taking account of whether the
// CNC is currently in inches or mm.
// Note that the CNC program should be using G43 H<n> to see any effect.
// z parameter is the Z axis height at touch-off point
// Returns 0 if OK, 1 if could not query host.
int update_tlo(double z)
{
    int units, TWORD, HWORD, DWORD;
    double tlo;
   
    if (VAR_CURRENT_TOOL <= 0)
        return 0;   // Ignore if no mounted tool
 
    if (GetMiscSettings(&units, &TWORD, &HWORD, &DWORD))    // Just for units
        return 1;
       
    tlo = STEPS_TO_MM(z + TC_THS_TLO);
    if (units != CANON_UNITS_MM)
        tlo /= 25.4;
 
    // Change Currently Selected Tool Length
    return SetToolLength(VAR_CURRENT_TOOL, tlo);
}


The extern functions (SetToolLength) are stolen from your sample code.  VAR_CURRENT_TOOL is the T number from the M6.  I'm assuming a 1:1 map between tools and tool slots, indices etc.

I always get the correct length set into the tool table, but other entries are getting deleted, and it goes to unexpected places in the table.

Regards,
SJH

Group: DynoMotion Message: 11400 From: Tom Kerekes Date: 4/15/2015
Subject: Re: Setting tool length offsets
Hi SJH,

I believe that has been fixed in the latest Test Version.  What Version are you using?

Regards
TK

Group: DynoMotion Message: 11401 From: Hardy Family Date: 4/15/2015
Subject: Re: Setting tool length offsets
Hi Tom,

I'm using v. 432.  I just noticed some other strangeness e.g. (according to NGC) g43 h0 should be the same as g49, but for me g43 h0 gives an inexplicable residual 2mm offset.

I'll give the test version a try.  (Is this going to be v. 433?)

Regards,
SJH


On Wed, Apr 15, 2015 at 3:58 PM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Hi SJH,

I believe that has been fixed in the latest Test Version.  What Version are you using?

Regards
TK

Group: DynoMotion Message: 11402 From: Hardy Family Date: 4/15/2015
Subject: Re: Setting tool length offsets
Where is the new version?

Regards,
SJH


On Wed, Apr 15, 2015 at 4:28 PM, Hardy Family <hardy.woodland.cypress@...> wrote:
Hi Tom,

I'm using v. 432.  I just noticed some other strangeness e.g. (according to NGC) g43 h0 should be the same as g49, but for me g43 h0 gives an inexplicable residual 2mm offset.

I'll give the test version a try.  (Is this going to be v. 433?)

Regards,
SJH


On Wed, Apr 15, 2015 at 3:58 PM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Hi SJH,

I believe that has been fixed in the latest Test Version.  What Version are you using?

Regards
TK

Group: DynoMotion Message: 11403 From: Hardy Family Date: 4/15/2015
Subject: Re: Setting tool length offsets
OK, I found version 433k, installed it and fixed the settings etc.  Note: the tcc67 with that version is broken, I had to overwrite it with the patched tcc67.exe.

It seems that setting the tool table from the kflop just goes in and sets the Nth table entry (with 0 being the first entry) regardless of the slot number which is set for that entry.  I think it is just a matter of looking in the table for a matching slot number, and modifying that entry.  Ideally, it should create a new entry if there is not one already there.

Regards,
SJH


On Wed, Apr 15, 2015 at 4:51 PM, Hardy Family <hardy.woodland.cypress@...> wrote:
Where is the new version?

Regards,
SJH


On Wed, Apr 15, 2015 at 4:28 PM, Hardy Family <hardy.woodland.cypress@...> wrote:
Hi Tom,

I'm using v. 432.  I just noticed some other strangeness e.g. (according to NGC) g43 h0 should be the same as g49, but for me g43 h0 gives an inexplicable residual 2mm offset.

I'll give the test version a try.  (Is this going to be v. 433?)

Regards,
SJH


On Wed, Apr 15, 2015 at 3:58 PM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Hi SJH,

I believe that has been fixed in the latest Test Version.  What Version are you using?

Regards
TK

Group: DynoMotion Message: 11404 From: Tom Kerekes Date: 4/15/2015
Subject: Re: Setting tool length offsets
Hi SJH,

Are you saying there is a problem?  The TWORD is the tool table index of the currently selected tool regardless of whether it was selected by slot number or ID.  So pass that back to change the length of currently selected tool.

Regards
TK

Group: DynoMotion Message: 11405 From: Hardy Family Date: 4/15/2015
Subject: Re: Setting tool length offsets
So there's a difference in these numbers?  My routine is called just out of an M6, where the tool slot is passed in a persist var.  That was what I was using.  Is the TWORD setting going to be different?  No problem using this if it is required, just curious as to why it would be different than the T passed to the M6 handler.

I still think there's a bug somewhere: if I pass "n" as the tool index in SetToolLength(), then it should update the tool table entry for slot n, not necessarily the n+1th item in the tool table (since the items aren't necessarily sorted).

Version 433k certainly solved the g43 problem I was having, but only if the tool table is ordered exactly by tool slot 0, 1, 2,...  Maybe I am just confused by the difference between tool slots, indices and IDs.  G-code is a bit of a mess in that respect. [My gast was particularly flabbered when I found that the tool table doesn't specify units!  Yes, I know, punch-card days, but you would have thought the guys at NIST of all people would have fixed that.]

Regards,
SJH


On Wed, Apr 15, 2015 at 7:38 PM, Tom Kerekes tk@... [DynoMotion] <DynoMotion@yahoogroups.com> wrote:
 

Hi SJH,

Are you saying there is a problem?  The TWORD is the tool table index of the currently selected tool regardless of whether it was selected by slot number or ID.  So pass that back to change the length of currently selected tool.

Regards
TK

Group: DynoMotion Message: 11410 From: Tom Kerekes Date: 4/16/2015
Subject: Re: Setting tool length offsets
Hi SJH,

Sorry it is so confusing.  I find it confusing also. 

Actually the M6 passes both the tool slot and the tool id (in the Var +1 location).  With the idea being the slot is what a tool changer most likely needs or maybe the id if the tool changer maintains those somehow.

But for changing the Tool Table the Tool Table entry index of the current tool is probably more useful.   

Regards
TK

Group: DynoMotion Message: 11411 From: ericncn Date: 4/16/2015
Subject: Re: Setting tool length offsets
Let me step in... we've discussed this other times but I still think that the G-Code needs to reference the tools, not the slots!  It's the M6 implementation routine that has to know which slot currently is the tool ID referenced by the M6 Txxx call, and make it transparent to the G-Code.

By the way, I've tried using the sample KFLOPManualToolChange.c and it always displays the message: "Change to Tool 0" regardless of the current tool ID.
It looks like persist.UserData[9] always contains zero, not the tool ID....

EC

---In DynoMotion@yahoogroups.com, <tk@...> wrote :

Hi SJH,

Sorry it is so confusing.  I find it confusing also. 

Actually the M6 passes both the tool slot and the tool id (in the Var +1 location).  With the idea being the slot is what a tool changer most likely needs or maybe the id if the tool changer maintains those somehow.

But for changing the Tool Table the Tool Table entry index of the current tool is probably more useful.   

Regards
TK

Group: DynoMotion Message: 11412 From: Tom Kerekes Date: 4/16/2015
Subject: Re: Setting tool length offsets
Hi EC,

You should be able to use Tool IDs or Slot numbers in the GCode.  The GCode will assume it is a Slot number if the number is 99 or less.  Numbers 100 or greater are considered Tool IDs.  As I just posted both the Slot and ID are then passed to the M6 routine.  If M6 is configured to use Var=9 then persist.UserData[9] will have the slot number not the ID.  The ID will be in the next Var persist.UserData[10].  So if you didn't specify a slot number in the tool table then persist.UserData[9] should be expected to be 0.

HTH
Regards
TK